Comme nous l’avions expliqué dans notre dossier sur les systèmes de fichiers, la FAT32 est arrivée en 1996, après la FAT16. Pour les amateurs d’archéologie, on rappellera que la FAT16 était maitre des lieux au lancement de Windows 95. Il faudra attendre la version OSR2 (OEM Service Release 2) pour que la FAT32 débarque.
Du FAT32 à 2 To pour les Insider sous Windows 11
La FAT32 propose pour rappel un codage sur 28 bits, avec une taille maximale de 4 Go pour les fichiers et de 2 To pour les partitions. Mais un point important est à préciser : les outils intégrés de Microsoft ne dépassaient pas 32 Go. Des logiciels tiers permettaient par contre de s’affranchir de cette limite arbitraire.
Près de 30 ans après la sortie de la FAT32, Microsoft dépasse enfin cette limite arbitraire de 32 Go dans Windows 11. Il faut pour cela être dans le canal Insider, disposer de la Preview Build 27686 (qui propose d’autres nouveautés) et utiliser la ligne de commande.
« Lors du formatage de disques à partir de la ligne de commande à l'aide de la commande "format", nous avons augmenté la limite de taille FAT32 de 32 Go à 2 To », soit le maximum permis par le système de fichiers. Et ça marche, comme l’indique Xeno sur X.
This is the output formatting a volume as FAT32 in 27686 pic.twitter.com/LcOsEZqMf3
— Xeno (@XenoPanther) August 15, 2024
Pour le moment, seule la ligne de commande est concernée, pas (encore ?) la boite de dialogue qui commence à bien accuser son âge. Cette fonctionnalité est sur le canal Insider et ne sera pas obligatoirement déployée sur les versions finales, affaire à suivre.
Une boite de dialogue temporaire… pendant 30 ans
En mars de cette année, Dave Plummer, ancien de chez Microsoft, est revenu sur cette fameuse interface graphique pour formater un périphérique de stockage. Elle a été écrite « un jeudi matin pluvieux chez Microsoft, fin 1994 », se souvient-il.
« Nous étions en train de porter les milliards de lignes de code de l'interface utilisateur de Windows 95 vers NT, et Format était l'un des domaines dans lesquels Windows NT était suffisamment différent de Windows 95 pour que nous ayons à créer une interface utilisateur personnalisée ».
Un passage par Visual C++ 2.0 plus tard, une première version était développée. « C'était il y a environ 30 ans, et la boite de dialogue est toujours ma version temporaire de ce jeudi matin, alors soyez prudent lorsque vous faites des solutions "temporaires" », s’amuse-t-il.
Il en profite pour rappeler que la limite des 32 Go était « un choix arbitraire ce matin-là, qui est resté comme un effet secondaire permanent. Alors, rappelez-vous… il n'y a pas de versions "temporaires" :) ».
Commentaires (48)
#1
#1.1
#1.2
Par contre il est possible qu'en terme de qualité du code, ça ne soit pas aux standards actuel et que Microsoft trouve que ça soit une bonne occasion et le refaire avec les API Windows modernes.
Historique des modifications :
Posté le 19/08/2024 à 10h42
Pas forcément. Le code source n'a probablement jamais fini dans un tiroir, le code des différents composant inclus dans Windows devant être recompilable, au minimum, pour permettre de supporter les nouvelles plateformes.
Par contre il est probable qu'en terme d'organisation du code, ça ne soit pas aux standards actuels.
Posté le 19/08/2024 à 10h47
Pas forcément. Le code source n'a probablement jamais fini dans un tiroir, le code des différents composant inclus dans Windows devant être recompilable, au minimum, pour permettre de supporter les nouvelles plateformes.
Par contre il est possible qu'en terme d'organisation du code, ça ne soit pas aux standards et que ça soit une bonne occasion et le refaire avec les API Windows modernes.
#1.3
#2
#3
Idem quand un stockage est crouillé au point de ne même plus identifier le système de fichier: Combien de personnes, même sans double boot, on-t'elles ainsi hypothéqué encore un peu plus les possibilités de récupération de leurs données (idéalement non sauvegardées) à cause de ce comportement incroyablement stupide?
#3.1
Pourtant, ce disque est parfaitement utilisable sous Linux (via le pilote NTFS-3G) et je peux tout à fait lire et manipuler des fichiers sur ce disque. Je peux même les copier sur une clef USB depuis Linux et les faire lire ensuite par Windows.
Si quelqu’un sait comment faire pour que Windows reconnaisse à nouveau ce disque, sans que ça n’oblige à le formater (je veux pas que ça touche aux fichiers déjà présents dessus), je prends.
#3.2
Le type de partition ne signifie pas le formatage de la partition. Mais un mauvais type peut empêcher Windows de reconnaitre la partition. Si c'est ça, la chance, c'est que c'est facilement changeable.
Je t'invite à regarder sous Linux le type de la partition (via fdisk par exemple), et voir si cela correspond à ce qu'attends Windows, et pas un truc "farfelu" genre "linux swap".
#3.3
#3.4
Quand tu as une partition swap, on s'attend effectivement à ce qu'elle soit utilisée pour du swap. Mais rien n'empêche d'avoir une partition marqué comme swap, mais d'y mettre un système de fichier et de monter ensuite la partition (bon, j'ai pas tenté dernièrement cette opération, mais j'ai déjà utilisé cette astuce par le passé).
C'est un peu le même principe que pour les extension de fichier si tu veux. On s'attend d'un .txt de contenir du texte et un .exe d'être un exécutable pour Windows. Mais rien n'empêche d'avoir un .exe qui contienne du texte et un .txt du binaire. Mais si tu essayes d'ouvrir un .exe qui contient du texte, tu ne vas pas avoir notepad qui s'ouvre, mais un message d'erreur t'indiquant que l'exécutable n'est pas valide.
En refouillant un peu, le problème que j'avais eu, c'était une partition du "mauvais type". J'avais formaté un disque en NTFS depuis Linux. Aucun problème sous Linux, mais impossible d'accéder au disque sous Windows. En cause, le type de partition qui était 0x86 au lieu de 0x87 (ou inversement, je ne sais plus l'ordre). Les deux étaient marquées comme étant des partitions "NTFS". C'est en faisant des tests et en comparant les partitions formatés sous Linux et sous Windows que je me suis rendu compte de ça. C'est con, j'ai mis un moment avant de trouver, mais après ça a marché sans aucun problème.
A moins d'éditer à la mano directement avec un éditeur hexadécimal le GPT directement sur disque, je pense qu'il y a peu de risque de flinguer sa partition GPT ou sa sauvegarde en utilisant des outils comme fdisk. Faire des conneries oui, bousiller complètement sa GPT, peu de chance.
#3.5
Donc ca arrive mais c'est rare et forcément toujours hautement suspicieux.
Sinon windows qui ne va pas voir direct dans la partition mais utilise une info redondante voir source d'erreur comme ton cas l'illustre c'est pas malin. Pas besoin de lire des étiquettes sur les étagères quand on peut voir comment c'est organisé dessus. Surtout que partitionnement et formatage sont le fait d'outils disjoints et que ce type de dépendance ne peut apporter que des ennuis. On peut avoir partitionné ily a 10 ans et reformater avec un FS qui n'existait alors pas depuis...
#3.6
Oui, Windows et Linux ne traitent pas de la même manière beaucoup de chose. Ce n'est pas parce que c'est différent que l'un est mieux que l'autre.
Historiquement, Windows a toujours monté les partitions par défaut, sans action de l'utilisateur, contrairement à Linux, où il fallait se farcir le /etc/fstab. Du coup, linux n'avait pas besoin de se fier au type de partition, car c'est l'utilisateur (administrateur du système) qui lui donnait la marche à suivre.
Aujourd'hui, le type de partition est encore utilisé, indépendamment du FS, et Linux le fait aussi maintenant (enfin les automounter), pour éviter de monter automatiquement les partitions qui n'ont pas à l'être (partition de recovery par exemple).
Donc c'est le DD qui est défaillant, pas les outils ;)
Historique des modifications :
Posté le 20/08/2024 à 08h27
Franchement, les discours le choix de Windows est nul, Linux c'est mieux, sans mieux comprendre les tenants et aboutissants, c'est fatiguant.
Oui, Windows et Linux ne traitent pas de la même manière beaucoup de chose. Ce n'est pas parce que c'est différent que l'un est mieux que l'autre.
Historiquement, Windows a toujours monté les partitions par défaut, sans action de l'utilisateur, contrairement à Linux, où il fallait se farcir le /etc/fstab. Du coup, linux n'avait pas besoin de se fier au type de partition, car c'est l'utilisateur (administrateur du système) qui lui donnait la marche à suivre.
Aujourd'hui, le type de partition est encore utilisé, indépendamment du FS, et Linux le fait aussi maintenant (enfin les automounter), pour éviter de monter automatiquement les partitions qui n'ont pas à l'être (partition de recovery par exemple).
#3.7
-Cycles de MAJ des outils de partitionnement/formatage qui peuvent poser pb avec l'évolution des FS supportés. Pire encore quand 2 OS différents se partagent une même machine.
-Se retrouver à toucher des tables de partition hors partitionnement initial, sur un formatage: Risque de planter tout le stockage (et rendre la machine impossible à booter) si pb lors de l'écriture ou coupure alim qui tombe mal... Ici, pas besoin d'un firmware de stockage buggé pour arriver d'un chemin différent au cas évoqué. Bref, une table de partition on l'écrit une fois puis on ne fait que la lire, toute approche différente c'est des risques évitables.
-Si je monte de l'ext4 manuellement, pas besoin de le spécifier au mount il reconnait et s'en démerde sous Linux, sauf s'il y a un pb (raison sans doute de la mention du type de FS dans le fstab) et je trouve plus sûr d'avoir le type de FS dans un fichier texte qu'une table de partition (on bénéficie en prime de la journalisation pour éviter une machine un-bootable si on ne touche pas à la partition de boot), puis au moins on est certain de la cohérence de vue d'un même OS avec lui-même (tandis qu'une table de partition peut être faite par l'un puis utilisée par l'autre).
#3.8
ça, on est d'accord.
Maintenant attention (car je pense que c'est de là que vient la méprise) : ce n'est pas parce que Windows tient compte du type de partition que celle-ci doit changer à chaque formatage. C'est seulement si le type de partition est inadéquat (=pas approprié au stockage de données) ta partition ne sera pas reconnue par Windows. Ca ne va pas plus loin que ça. Mais ça ne veut pas dire qu'à chaque formatage ou changement de FS, tu changes le type de partition.
Problème de l'oeuf et de la poule ;) Pour avoir les FS, il te faut monter un FS.
Je me demande aussi si le problème initial ne pourrait pas être lié aux SMART. Ca ne m'étonnerait pas que Windows ne monte pas automatiquement un disque qui présenterait des anomalies, afin de protéger les données.
#3.9
Le pb d'oeuf et de poule ne se pose que pour la partition racine... qui si elle a un pb au point de ne même plus savoir identifier le FS avec ses magic number et autres métadonnées ne risque pas d'être vue bootable par le boot-loader, qui a en prime toutes chances d'implementer un simple reader très incomplet vs le support FS complet sous OS (j'ai vu u-boot sur de l'embarqué incapable de rejouer un journal Ext4 sur coupure d'alim: Si cela tombait sur un fichier utile au boot, même une simple config dont la version antérieure n'aurait pas posé de pb, tu étais coincé mais extraire le stockage et le monter sur un PC Linux corrigeait le pb derrière ton dos sans action utilisateur. C'était un rollback sur la partition/version passive ; Idem avec des UEFI intégrant un driver Ext4, de ce côté les inodes 64bit devenues le défaut sur une nouvelle version de mkfs il y a 6 ou 7 ans lui posaient soudain pb sans rien avoir changé aux outils/options utilisées pour créer les médias de boot).
Le côté SMART n'est pas intégré direct au montage, trop spécifique (stockages USB, image montée via un device loop...). Un montage ou re-montage read-only en cas de pb c'est courant mais c'est l'OS qui gère. Parfois c'est même le controleur du stockage qui le passe RO au niveau du matériel (systématique sur les SSD).
Historique des modifications :
Posté le 20/08/2024 à 13h24
Si on ne modifie pas côté partitionnement on risque de se retrouver dans ton cas vécu avec une ex partition swap convertie en stockage qui ne sera pas exploitable d'un OS qui se base avant tout sur les infos de la table de partition. AMHA, le mieux est encore que le dangereux couteau qui sert à couper le gâteau reste bien séparé de la cuiller servant à le manger.
Le pb d'oeuf et de poule ne se pose que pour la partition racine... qui si elle a un pb au point de ne même plus savoir identifier le FS avec ses magic number et autres métadonnées ne risque pas d'être vue bootable par le boot-loader, qui a en prime toutes chances d'implementer un simple reader très incomplet vs le support FS complet sous OS (j'ai vu u-boot sur de l'embarqué incapable de rejouer un journal Ext4 sur coupure d'alim: Si cela tombait sur un fichier utile au boot, même une simple config dont la version antérieure n'aurait pas posé de pb, tu étais coincé mais extraire le stockage et le monter sur un PC Linux corrigeait le pb derrière ton dos sans action utilisateur. C'était un rollback sur la partition/version passive ; Idem avec des UEFI intégrant un driver Ext4, de ce côté les inodes 64bit devenues le défaut sur une nouvelle version de mkfs il y a 6 ou 7 ans lui posaient soudain pb sans rien avoir changé aux outils/options utilisées pour créer les médias de boot).
Le côté SMART n'est pas intégré direct au montage, trop spécifique (stockages USB, image montée via un device loop...). Un montage ou re-montage read-only en cas de pb c'est courant mais c'est l'OS qui gère.
#3.10
Ce n'était pas un changement permanent, juste temporaire le temps de pouvoir résoudre des problèmes, et où j'avais besoin d'un espace de stockage temporaire le temps de réaliser mon opération (et sans possibilité de connecter une clé usb ou autre, sinon, c'est pas drole).
Ben oui, mais il se pose. Et plutôt que d'avoir plusieurs mécanismes en place, autent en avoir le minimum. Et le système de partition est obligatoire en plus d'être indépendant de l'OS ;)
Après, que les bootloader n'ait qu'un support complet, ça ne m'étonne pas. Et dans un sens, tant mieux. Ils n'ont besoin que d'un accès en lecture, et ce n'est pas le rôle d'un bootloader de "réparer" les défaillances d'un FS.
Détrompe toi. Certains BIOS/UEFI désactive purement et simplement l'accès au disque si le rapport SMART n'est pas bon. C'est vrai pour les disques internes (SATA, nvme, ...). Mais je ne pense pas que cela soit le cas pour les disques USB (le blocage par le BIOS j'entends)
Par contre, cela ne m'étonnerait pas du tout que Windows empêche le montage d'un disque dont le rapport est mauvais. Enfin juste mauvais non, car j'ai déjà pu monter des disques USB présentant quelques défaillances sous Windows, mais les défaillances critiques peuvent peut-être être bloquantes (et c'est en écrivant ce commentaire que je me rends compte d'une explication plausible à un disque USB que je ne peux plus utiliser sous Windows).
#3.11
Je n'ai pas vraiment dit le contraire, mais souligné que cette mention du fstab n'est potentiellement utile que pour un FS cassé au point qu'un mount ne saurait plus l'identifier automatiquement.
Et que rendu là, une partition racine (ou le fstab est logé) aurait toutes chances d'être bien trop mal en point pour être bootable, même en lisant le type de FS en table (sans pb théorique de poule/oeuf)!
Bref, les cas où lire l'info en table serait en pratique salvateur ça doit pas faire bézef. En tout cas AMHA loin de compenser les risques évoqués si l'on veut tenir cela à jour (ou pas) en cas de changement de FS.
#3.12
Ce n’est qu’un an plus tard, quand j’ai voulu copier l’ISO de Windows 11 23H2 que j’avais mise dessus sur le PC qu’on m’a offert à Noël, que j’ai découvert que Windows ne reconnaissait plus le FS du disque. Et ce, sur les deux machines Windows que j’ai chez moi, de même que le PC portable dont ma tante a hérité.
#3.13
As tu essayé de faire une vérification manuelle du disque sous Windows, avec CHKDSK par exemple ? Car tu as fais un truc que je trouve funky et qui pourrait causer ce problème : tu as passé ton système de fichiers en lecture seule, mais tu as continué d'écrire dessus sous Linux. S'il y a des checksums de positionné au moment où le disque est passé en lecture seul, mais pas mis à jour depuis (car modif faite depuis linux), cela pourrait expliquer que Windows voit le système de fichier comme corrompu et t'invite donc à le formater.
De même, ntfs-3 reste limité sur certains aspects, comme la journalisation (ce qui pourrait aussi expliquer le comportement que tu observes)
[edit]
ou virer l'attribut read-only s'il est présent. Car que peut faire Windows si le système de fichier est corrompue, mais que la partition est marquée comme readonly ? Impossible de la réparer => formatage.
Historique des modifications :
Posté le 20/08/2024 à 20h52
Clairement, le type d'une partition ne change pas tout seul. Donc si ça fonctionnait avant, peu de chance que ce soit ça.
As tu essayé de faire une vérification manuelle du disque sous Windows, avec CHKDSK par exemple ? Car tu as fais un truc que je trouve funky et qui pourrait causer ce problème : tu as passé ton système de fichiers en lecture seule, mais tu as continué d'écrire dessus sous Linux. S'il y a des checksums de positionné au moment où le disque est passé en lecture seul, mais pas mis à jour depuis (car modif faite depuis linux), cela pourrait expliquer que Windows voit le système de fichier comme corrompu et t'invite donc à le formater.
De même, ntfs-3 reste limité sur certains aspects, comme la journalisation (ce qui pourrait aussi expliquer le comportement que tu observes)
#4
Ça ne ferait donc que 25 ans (Windows 2000 est sorti en 1999) que cette limitation artificielle existe, et nombreux sont ceux qui pensent qu’elle n’était motivée que par le désir de Microsoft de pousser à l’usage de NTFS à la place de FAT32, surtout en tant que volume système.
#4.1
Le 1er PC que j'ai eu à moi (un 486DX33), en 1993, c'était 130Mo de HDD et 4Mo de RAM: Ça permettait déjà de jouer à DOOM.
#4.2
#4.4
C'était une bonne pratique de passer à NTFS de toutes façons, sauf à manipuler de gros fichier et de se moquer de tout perdre pour un petit bug...
#4.6
Non : c’était toujours 32 kio par cluster, donc 32 kio minimum par fichier (là où NTFS reste par défaut à 4 kio).
Mais là n’était pas la question, de toute manière : je venais pas discuter de l’intérêt de NTFS sur FAT32 (personne ne le discutera, tellement il est évident ; FAT32 n’ayant pour lui que le fait d’être reconnu par tout le monde à la différence de NTFS, même aujourd’hui sur des télés, consoles de jeu ou lecteurs Blu-ray de salon), mais du fait que la limite à 32 Gio sur les volumes FAT32 n’existait pas, même chez MS, avant la sortie de Windows 2000 (les Windows NT précédents ne sont pas concernés car ils ne prenaient pas FAT32 en charge, pas même Windows NT 4.0 avant qu’on lui ajoute le SP4 ou 6, je crois). Et que d’aucuns y ont vu une manœuvre – dont l’entreprise est passée maître du genre au cours de son histoire, surtout sous l’ère Gates – pour forcer la main aux utilisateurs pour migrer vers NTFS, alors qu’ils auraient préféré rester en FAT32 (pour des raisons diverses, comme celle de l’universalité en cas de dual boot avec un Linux, par exemple).
Si Dave Plummer dément cette intention, très bien, mais il le fait bien (25 ans !) trop tard, car cette hypothèse a bien eu le temps de s’ancrer dans les esprits et de devenir « la » vérité pour l’opinion, et elle ne va pas en être éjectée en un claquement de doigts…
#4.8
De toutes façons, la limite à 4go des fichiers, le manque de sécu et de métadonnées ont tué la fat32 pour les jeux et les films et les os.
#4.3
La limitation n'était que pour le programme de formatage sous 2000 et suivant , et uniquement pour le format natif , la prise en charge de plus de 32gig était sans problême car pas limitée
( par exemple avec un utilitaire comme fat32format )
#4.5
Windows NT c'est NTFS pour raisons qu'il y a besoin des droits ACL pour le système lui-même, pour des raisons évidentes de sécurités.
#4.7
* FAT32 n’est apparu qu’en 1996 et, s’il paraît que Windows 95 OSR 2 fut le premier à le prendre en charge, je me rappelle n’en avoir entendu parler que lors de la sortie de Windows 98 deux ans plus tard, où ce FS était annoncé en grandes pompes parmi les nouveautés majeures, avec Windows Update et Active Desktop.
* Côté Windows NT (qui était conçu par une équipe différente de celle des Windows basés sur MS-DOS, y compris la série Windows 9x/ME), il aura fallu attendre Windows 2000 pour que FAT32 soit intégré nativement. Ni Windows NT 4.0, ni encore moins les précédents, ne le prenaient en charge (il fallait installer un Service Pack pour que WinNT 4.0 reconnaisse enfin ce FS, peut-être le SP4 ou le 6).
* Windows NT 3.5 était encore basé sur l’UI de Windows 3.1, donc sa boîte de dialogue de formatage était organisée tout à fait différemment.
Historique des modifications :
Posté le 20/08/2024 à 10h11
Comme je viens de dire dans le message que je viens de poster (le #4.6) : cette vérification est inutile, et pour trois raisons :
* FAT32 n’est apparu qu’en 1996 et, s’il paraît que Windows 95 OSR 2 fut le premier à le prendre en charge, je me rappelle n’en avoir entendu parler que lors de la sortie de Windows 98 deux ans plus tard, où ce FS était annoncé en grandes pompes parmi les nouveautés majeures, avec Windows Update et Active Desktop.
* Côté Windows NT (qui était conçu par une équipe différente de celle des Windows basés sur MS-DOS, y compris la série Windows 9x/ME), il aura fallu attendre Windows 2000 pour que FAT32 soit intégré nativement. Ni Windows NT 4.0, et encore moins les précédents, ne le prenaient en charge (il fallait installer un Service Pack pour que WinNT 4.0 reconnaisse enfin ce FS, peut-être le SP4 ou le 6).
* Windows NT 3.5 était encore basé sur l’UI de Windows 3.1, donc sa boîte de dialogue de formatage était organisée tout à fait différemment.
#5
#5.1
- Faites moi un POC
- Le voila
- Trés bien, ça correspond à ce que je veux. mettez le en production
#5.2
#6
#6.1
#7
Si on restreint la réflexion aux formats voulus par M$ (les siens propres, donc), de souvenir, il me semblait que justement NTFS (v1 puis v2 si je me souviens là aussi bien) venait compenser FAT32, notamment au niveau des descripteurs de sécurité.
Historique des modifications :
Posté le 20/08/2024 à 21h29
Je ne comprends pas de quel(s) intérêt(s) FAT32 dispose(nt) par rapport à d'autres formats existants.
Si on restreint la réflexion aux formats voulus par M$ (ses propres, donc), de souvenir, il me semblait que justement NTFS (v1 puis v2 si je me souviens là aussi bien) venait compenser FAT32, notamment au niveau des descripteurs de sécurité.
#7.1
De plus, les partitions EFI des systèmes récents en UEFI sont formatées en FAT32, pas en NTFS. Seule la partition contenant le dossier Windows l’est. Même avec Linux en mono boot, cette partition EFI est en FAT32 et pas en Ext4, Btrfs ou XFS.
#7.2
#7.3
2. Va dire ça aux fabricants de disques durs externes qui préformatent leurs produits en NTFS… Là aussi, qui va reformater après dans un autre FS, à part des gens qui n’ont que du Linux ou de l’Apple chez eux et qui auront envie de les passer en Ext4 ou autre pour Linux, ou en APFS pour macOS (mais ça implique que ces disques ne sortiront pas de chez eux ou ne seront jamais branchés sur autre chose que du Linux/macOS) ?
#7.5
#7.4
Naquenaquenaireuh... Bleblebelebeleuh... Vi je retourne en maternelle...
Historique des modifications :
Posté le 21/08/2024 à 11h06
Et on ne le dit pas assez, mais FAT/ ExFAT, en plus d'être reconnu par quasi-toutes les distris Linux + macOS, est plus rapide que NTFS / EXT4 / HFS / APFS / toussketuveuh !
Naquenaquenaireuh... Bleblebelebeleuh... Vi je retourne en maternelle...
#7.7
En performance brute sur un système de fichier fraichement mis en place, c'est le périphérique qui est testé.
Sur un système de fichier qui a vécu, il faut penser à la fragmentation, et FAT ne prévoit juste… rien. Ça sent la douille, non ?
Et puis en conditions réelles, avec mix de petits & gros fichiers, ça m'étonnerait bien que les travaux sur ext aient obtenu moins bien que l'absence des mêmes travaux sur FAT (qui a les mêmes spécifications depuis le début, simplement étendues semble-t-il).
Expliquer en un commentaire que la journalisation ext ne sert à rien, alors que c'est l'évolution majeure entre ext2 & ext4.
À moins que ce soit du pur troll ?
Historique des modifications :
Posté le 22/08/2024 à 13h49
Ça sort d'où cette historie de performance ?
En performance brute sur un système de fichier fraichement mis en place, c'est le périphérique qui est testé.
Sur un système de fichier qui a vécu, il faut penser à la fragmentation, et FAT ne prévoit juste… rien. Ça sent la douille, non ?
Et puis en conditions réelles, avec mix de petits & gros fichiers, ça m'étonnerait bien que les travaux sur ext aient obtenu moins bien que l'absence des mêmes travaux sur FAT (qui a les mêmes spécifications depuis le début, simplement étendues semble-t-il).
Expliquer en un commentaire que la journalisation ext ne sert à rien, alors que c'est l'évolution majeure entre ext2 & ext4.
À moins que ce soit du pur troll ?
#7.8
Lors de lecture et l'écriture de petits fichiers, par contre, c'est NTFS qui remporte la course.
EDIT : Et je n'ai absolument rien dit concernant la journalisation, je ne sais pas d'où tu sors ça ? Et pour la fragmentation, tu veux me faire dire ce que je n'ai pas dit ?
Je parle uniquement de vitesse pure, rien d'autre.
Historique des modifications :
Posté le 22/08/2024 à 14h20
Sur ce lien, tu verras qu'en lecture et écriture sur de moyens et gros fichiers, Fat / ExFAT est légèrement plus rapide.
Lors de lecture et l'écriture de petits fichiers, par contre, c'est NTFS qui remporte la course.
#7.6
Tout ID n'a nécessairement qu'une signification locale, sauf si tu l'inscrit dans un référentiel universel (ce qui est nécessaire pour que des UID deviennent des UUID - GUID chez M$). C'est évidemment bien souvent inapplicable.
#7.9
Pour répondre à ta question, on pourrait imaginer stocker les droits avec un nom, ça donnerait l’illusion que ça marche si le nom est le même. Ça poserait tout autant de problème, mais serait peut-être plus intuitif pour les non-informaticiens.
#8
#8.1
Oh, et si tu as un PC récent en UEFI : FAT32 est le FS de la partition EFI, donc tous les gens ayant des PC avec UEFI sont de facto des utilisateurs de FAT32.
Historique des modifications :
Posté le 22/08/2024 à 12h34
Je ne doute pas que tu en fais partie, d’ailleurs. Fais le tour de toutes tes clefs USB et autres supports de stockage : tu en as forcément en FAT32 (ou ils l’étaient au moins d’usine).
#8.2
#8.4
(J’avoue avoir buggué une seconde en lisant la notification : « Triton vous a répondu ! »…
#8.3